home *** CD-ROM | disk | FTP | other *** search
/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / mini / Term-Firewall < prev    next >
Text File  |  1997-08-07  |  11KB  |  244 lines

  1.   Using Term to Pierce an Internet Firewall
  2.   Barak Pearlmutter, bap@cs.unm.edu
  3.   15-Jul-1996
  4.  
  5.   Directions for using ``term'' to do network stuff through a TCP fire¡
  6.   wall that you're not supposed to be able to.
  7.  
  8.   1.  Disclaimer
  9.  
  10.   !!! READ THIS IMPORTANT SECTION !!!
  11.  
  12.   I hereby disclaim all responsibility for this hack.  If it backfires
  13.   on you in any way whatsoever, that's the breaks.  Not my fault.  If
  14.   you don't understand the risks inherent in doing this, don't do it.
  15.   If you use this hack and it allows vicious hackers to break into your
  16.   company's computers and costs you your job and your company millions
  17.   of dollars, well that's just tough nuggies.  Don't come crying to me.
  18.  
  19.   2.  Copyright
  20.  
  21.   Unless otherwise stated, Linux HOWTO documents are copyrighted by
  22.   their respective authors. Linux HOWTO documents may be reproduced and
  23.   distributed in whole or in part, in any medium physical or electronic,
  24.   as long as this copyright notice is retained on all copies. Commercial
  25.   redistribution is allowed and encouraged; however, the author would
  26.   like to be notified of any such distributions.
  27.  
  28.   All translations, derivative works, or aggregate works incorporating
  29.   any Linux HOWTO documents must be covered under this copyright notice.
  30.   That is, you may not produce a derivative work from a HOWTO and impose
  31.   additional restrictions on its distribution. Exceptions to these rules
  32.   may be granted under certain conditions; please contact the Linux
  33.   HOWTO coordinator at the address given below.
  34.  
  35.   In short, we wish to promote dissemination of this information through
  36.   as many channels as possible. However, we do wish to retain copyright
  37.   on the HOWTO documents, and would like to be notified of any plans to
  38.   redistribute the HOWTOs.
  39.  
  40.   If you have questions, please contact Greg Hankins, the Linux HOWTO
  41.   coordinator, at gregh@sunsite.unc.edu via email, or at +1 404 853
  42.   9989.
  43.  
  44.   3.  Introduction
  45.  
  46.   The "term" program is normally used over a modem or serial line, to
  47.   allow various host-to-host services to flow along this simple serial
  48.   connection.  However, sometimes it is useful to establish a term
  49.   connection between two machines that communicate via telnet.  The most
  50.   interesting instance of this is for connecting two hosts which are
  51.   separated by ethernet firewalls or SOCKS servers.  Such firewalls
  52.   provides facilities for establishing a telnet connection through the
  53.   firewall, typically by using the SOCKS protocol to allow inside
  54.   machines to get connections out, and requiring outside users to telnet
  55.   first to a gateway machine which requires a one-time password.  These
  56.   firewalls make it impossible to, for instance, have X clients on an
  57.   inside machine communicate with an X server on an outside machine.
  58.   But, by setting up a term connection, these restrictions can all be
  59.   bypassed quite conveniently, at the user level.
  60.  
  61.   4.  The basic procedure
  62.  
  63.   Setting up a term connection over a telnet substrate is a two-phase
  64.   process.  First your usual telnet client is used to set up a telnet
  65.   connection and log in.  Next, the telnet client is paused and control
  66.   of the established telnet connection is given to term.
  67.   5.  Detailed directions
  68.  
  69.   In detail, the process goes like this.
  70.  
  71.   First, from a machine inside the firewall, telnet to a target machine
  72.   outside the firewall and log in.
  73.  
  74.   Unless you are under linux and will be using the proc filesystem (see
  75.   below) make sure your shell is an sh style shell.  Ie if your default
  76.   shell is a csh variant, invoke telnet by
  77.  
  78.        (setenv SHELL /bin/sh; telnet machine.outside)
  79.  
  80.   After logging in, on the remote (outside) machine invoke the command
  81.  
  82.        term -r -n off telnet
  83.  
  84.   Now break back to the telnet prompt on the local (inside) machine,
  85.   using ^] or whatever, and use the telnet shell escape command ! to
  86.   invoke term,
  87.  
  88.        telnet> ! term -n on telnet >&3 <&3
  89.  
  90.   Et voila!!!
  91.  
  92.   (If you have a variant telnet, you might have to use some other file
  93.   descriptor than 3; easy to check using strace.  But three seems to
  94.   work on all bsd descendent telnet clients I've tried, under both SunOS
  95.   4.x and the usual linux distributions.)
  96.  
  97.   Some telnet clients do not have the ! shell escape command.  Eg the
  98.   telnet client distributed with Slackware 3.0 is one such client.  The
  99.   sources that the Slackware telnet client is supposedly built from,
  100.  
  101.        ftp://ftp.cdrom.com:/pub/linux/slackware-3.0/source/n/tcpip/NetKit-B-0.05.tar.gz
  102.  
  103.   have the shell escape command.  A simple solution is therefore to
  104.   obtain these sources and recompile them.  This unfortunately is a task
  105.   I have had no luck with.  Plus, if you are running from inside a SOCKS
  106.   firewall, you will need a SOCKSified telnet client anyway.  To that
  107.   end, I was able to compile a SOCKSified telnet client from
  108.  
  109.        ftp://ftp.nec.com/pub/security/socks.cstc/socks.cstc.4.2.tar.gz
  110.  
  111.   or if you're outside the USA,
  112.  
  113.   ftp://ftp.nec.com/pub/security/socks.cstc/export.socks.cstc.4.2.tar.gz
  114.  
  115.   Alternatively, under linux kernels up to 1.2.13, you can pause the
  116.   telnet with ^]^z, figure out its pid, and invoke
  117.  
  118.        term -n on -v /proc/<telnetpid>/fd/3 telnet
  119.  
  120.   This doesn't work with newer 1.3.x kernels, which closed some mysteri¡
  121.   ous security hole by preventing access to these fd's by processes
  122.   other than the owner process and its children.
  123.  
  124.   6.  Multiple term sockets
  125.  
  126.   It is a good idea to give the term socket an explicit name.  This is
  127.   the "telnet" argument in the invocations of term above.  Unless you
  128.   have the TERMSERVER environment variable set to telnet as appropriate,
  129.   you invoke term clients with the -t switch, e.g. "trsh -t telnet".
  130.  
  131.   7.  The ~/.term/termrc.telnet init file
  132.  
  133.   I have checked line clarity using linecheck over this medium.  I
  134.   expected it to be completely transparent, but it is not.  However, the
  135.   only bad character seems to be 255.  The ~/.term/termrc.telnet I use
  136.   (the .telnet is the name of the term connection, see above) contains:
  137.  
  138.        baudrate off
  139.        escape 255
  140.        ignore 255
  141.        timeout 600
  142.  
  143.   Perhaps it could be improved by diddling, I am getting a throughput of
  144.   only about 30k cps over a long-haul connection through a slow
  145.   firewall.  Ftp can move about 100k cps over the same route.  A
  146.   realistic baudrate might avoid some timeouts.
  147.  
  148.   8.  Direction
  149.  
  150.   Obviously, if you are starting from outside the firewall and zitching
  151.   in using a SecureID card or something, you will want to reverse the
  152.   roles of the remote vs local servers given above.  (If you don't
  153.   understand what this means, perhaps you are not familiar enough with
  154.   term to use the trick described in this file responsibly.)
  155.  
  156.   9.  Security
  157.  
  158.   This is not much more of a vulnerability than the current possibility
  159.   of having a telnet connection hijacked on an unsecured outside
  160.   machine.  The primary additional risk comes from people being able to
  161.   use the term socket you set up without you even being aware of it.  So
  162.   be careful out there.  (Personally, I do this with an outside machine
  163.   I know to be pretty secure, namely a linux laptop I maintain myself
  164.   that does not accept any incoming connections.)
  165.  
  166.   Another possibility is to add "socket off" to the remote
  167.   ~/.term/termrc.telnet, or add "-u off" to invocation of term.  This
  168.   prevents the socket from being hijacked from the remote end, with only
  169.   a minor loss of functionality.
  170.  
  171.   10.  Telnet mode
  172.  
  173.   Be sure the remote telnetd is not in some nasty seven-bit mode.  Or if
  174.   it is, you have to tell term about it when you invoke term, by adding
  175.   the -a switch at both ends.  (I sometimes use "^] telnet> set outbin"
  176.   or "set bin" or invoke telnet with a -8 switch to put the connection
  177.   into eight-bit mode.)
  178.  
  179.   11.  Bugs and term wish list
  180.  
  181.   The linecheck program has some problems checking telnet connections
  182.   sometimes.  This is sometimes because it doesn't check the return code
  183.   of the read() call it makes.  For network connections, this call to
  184.   read() can return -1 with an EINTR (interrupted) or EAGAIN (try again)
  185.   error code.  Obviously this should be checked for.
  186.  
  187.   There are a number of features that could ease the use of term over
  188.   telnet.  These primarily relate to an assumption that influenced the
  189.   design of term, namely that the connection is low bandwidth, low
  190.   latency, and somewhat noisy.
  191.  
  192.   A telnet connection is in general high bandwidth, high latency, and
  193.   error free.  This means that the connection could be better utilized
  194.   if (a) the maximum window size was raised, well above the limit
  195.   imposed by term's N_PACKETS/2=16, (b) there was an option to turn off
  196.   sending and checking packet checksums, and (c) larger packets were
  197.   permitted when appropriate.
  198.  
  199.   Also, to enhance security, it would be nice to have a term option to
  200.   log all connections through the socket it monitors to a log file, or
  201.   to stderr, or both.  This would allow one to see if one's term
  202.   connection is being subverted by nasty hackers on the outside insecure
  203.   machine.
  204.  
  205.   12.  Tricks that don't seem to work
  206.  
  207.   Some telnet clients and servers agree to encrypt their communications,
  208.   to prevent evesdropping on the connection.  Unfortunately, the hack
  209.   used above (using the network connection that the telnet client has
  210.   set up while the telnet client is idle) won't work in that case.
  211.   Instead, one really must go through the telnet client itself, so it
  212.   can do its encryption.  It seems like that requires a simple hack to
  213.   the telnet client itself, to add a command that runs a process with
  214.   its stdin and stdout are connected to the live telnet connection.
  215.   This would also be useful for various 'bots, so perhaps someone has
  216.   already hacked it up.
  217.  
  218.   13.  Related resources
  219.  
  220.   A vaguely related trick is to SOCKSify one's Term library.  Details,
  221.   including patches to SOCKS, are available from Steven Danz
  222.   <danz@wv.mentorg.com>.
  223.  
  224.   14.  Acknowledgments
  225.  
  226.   Thanks for valuable suggestions from:
  227.  
  228.   ╖  Gary Flake   <flake@scr.siemens.com>
  229.  
  230.   ╖  Bill Riemers <bcr@physics.purdue.edu>
  231.  
  232.   ╖  Greg Louis   <glouis@dynamicro.on.ca>
  233.  
  234.        Extra copy of IMPORTANT DISCLAIMER --- BELIEVE IT!!!
  235.  
  236.        I hereby disclaim all responsibility for this hack.  If it
  237.        backfires on you in any way whatsoever, that's the breaks.
  238.        Not my fault.  If you don't understand the risks inherent in
  239.        doing this, don't do it.  If you use this hack and it allows
  240.        vicious hackers to break into your company's computers and
  241.        costs you your job and your company millions of dollars,
  242.        well that's just tough nuggies.  Don't come crying to me.
  243.  
  244.